1. Statement of the Technical Field
The present invention relates to the field of application component installation, and more particularly to dependency management during the installation of upgraded application components.
2. Description of the Related Art
Though often overlooked, application installation is a prerequisite to interacting with a software application. Specifically, in most circumstances, an application can be properly executed only subsequent to the completion of a successful installation process. At the minimum, a typical software application installation requires a transfer of files to the file structure of a computing system, and the configuration of the computing system to particularly interact with the software application. Ordinarily, the configuration of the computing system includes the addition or modification of registry settings, the addition or modification of entries to one or more initialization files, or both.
In the context of an application installation meant to upgrade the components of an application, oftentimes, simply replacing application out-dated versions of application components with newer versions of components will not alone suffice as a complete application upgrade. Rather, in an era of code re-use, shared libraries, and interdependent program objects, replacing a single application component can have a dramatic effect upon other separate, but independent applications. Common disastrous consequences include altered and now incompatible application programming interfaces (APIs), re-positioned application objects, and removed application objects. In all cases, an application dependency can be broken simply by upgrading the application components of another, unrelated application.
Whereas application component upgrades can be problematic generally, in an autonomic system, the problem can be particularly acute. For the uninitiated, autonomic computing systems self-regulate, self-repair and respond to changing conditions, without requiring any conscious effort on the part of the computing system operator. To that end, the computing system itself can bear the responsibility of coping with its own complexity. The crux of autonomic computing relates to eight principal characteristics:                I. The system must “know itself” and include those system components which also possess a system identify.        II. The system must be able to configure and reconfigure itself under varying and unpredictable conditions.        III. The system must never settle for the status quo and the system must always look for ways to optimize its workings.        IV. The system must be self-healing and capable of recovering from routine and extraordinary events that might cause some of its parts to malfunction.        V. The system must be an expert in self-protection.        VI. The system must know its environment and the context surrounding its activity, and act accordingly.        VII. The system must adhere to open standards.        VIII. The system must anticipate the optimized resources needed while keeping its complexity hidden from the user.        
Thus, in keeping with the principles of autonomic computing, an upgrade to application componentry must not only account for the seamless installation and configuration of the upgraded application, but also the impact of the upgrade upon dependencies must be considered. Specifically, it will be of paramount concern to the autonomic system that dependent applications are not “broken” in consequence of changing APIs, moved application elements, modified application elements, and removed application elements.
Presently, several application upgrade strategies exist. One such well-known strategy includes the venerable “ReadMe” file. In this strategy, software developers provide a list, typically as standard prose, of components in the upgraded application which have changed, along with a characterization of how the components have changed. Subsequently, during installation, an application administrator can peruse the contents of the list to determine the level of exposure faced by dependencies in view of the proposed application upgrade. As it will be recognized by one skilled in the art, however, the creation and use of a conventional ReadMe file can be both tedious and unreliable.
It will also be well understood by those skilled artisans that automated methods exist at least to remediate the tedium associated with the conventional ReadMe file. Specifically, various programming tools have been developed through which application component dependencies can be identified among system elements. Prior to any installation effort, the programming tool can be executed so as to determine the risk of undertaking the application upgrade. Still, this process lacks the granularity necessary to definitively determine what components may have changed in consequence of an upgrade. As a result, the analysis can consume substantial processing resources without producing the analysis necessary to truly identify the upgrade risk to specific dependencies.